J) 




Europaisches Patentamt 
European Patent Office 
Office europeen des brevets (£) Publication number: 0 565 314 A2 

EUROPEAN PATENT APPLICATION 



@ Application number: 93302613.0 
(3) Date of filing : 01.04.93 



© int. Ci. 5 : G06F 15/20, H04L 9/32 



(30) Priority : 06.04.92 US 863552 

@ Date of publication of application : 
13.10.93 Bulletin 93/41 

@ Designated Contracting States : 

AT BE CH DE DK ES FR GB GR IE IT U LU NL 
PT SE 

(7j) Applicant : Fischer, Addison M. 
60 14th Avenue South 
Naples Florida 33942 (US) 



(72) Inventor : Fischer, Addison M. 
60 14th Avenue South 
Naples Florida 33942 (US) 

(74) Representative : Evershed, Michael et al 
Saunders & Dolleymore 9, Rickmansworth 
Road 

Watford Hertfordshire WD1 7HE (GB) 



(54) Method and apparatus for creating, supporting, and using travelling programs. 



< 



in 



LU 



(57) A method and apparatus for creating, sup- 
porting and using a travelling program is dis- 
closed. A "travelling program" is a digital data 
structure which includes a sequence of instruc- 
tions and associated data and which has the 
capability of determining at least one next desti- 
nation or recipient for receiving the travelling 
program and for transmitting itself together 
with all relevant data determined by the prog- 
ram to the next recipient or destination. The 
travelling program can compute, according to 
any algorithm whatsoever, the digital material 
which is to be signed, and also, as needed, the 
digital material which is to be verified. The 
present invention also allows the program to 
conditionally decide, based on any known 
criteria, which users should participate in the 
signature process. The present invention also 
uses digital signatures to allow the travelling 
program to provide other types of valuable 
authentication. For example, as a security con- 
venience the present invention allows for the 
digital signature authentication of the entire 
transmission from one user to another. This 
includes the travelling program itself, its vari- 
ables, and any ancillary data or files. The pre- 
sent invention provides a unique mechanism for 
automating data collection among a group of 
users. The travelling program may be sent to 
one user, attach (or detach) relevant data files 
and move on to the next user. Data or files, 
collected from one or more users can be depo- 
sited with another user, or accumulated for 
batched processing as desired. This methodo- 
logy eliminates the need for individual users to 
be counted on to transmit all the required data 
in the required format The present invention 
also efficiently performs electronic document 
interchange (EDI) in the context of a travelling 
program which sends itself from user to the 
next within an organization, collecting, editing 
and approving data. 
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FIELD OF THE INVENTION 



The present invention relates to a method and apparatus for creatine a "travniiinn- n m nr 3m k *u 
by create a powerful tool for processing, authenticating, and collecting data at JE^ ; computer nodls 
BACKGROUND AND SUMMARY OF THE INVENTION 

Within an organization, documents are often moved manually. A mail or delivery service is often emnlo^H 
when documents are required to be transmitted between organizations P ^ 

Techniques for electronically transmitting documents within an organization and between conization* am 
well known. The rapid growth of electronic mail systems, electronic transfer system and ^theShavTse ved 

ssr^ss transactions and e,iminate some of the maJi ~ ^~z: t 

One prior art methodology for automatically transferring information between user* it™ ■♦»,• 
The electronic form methodology is very limited in many respects For example if thedata™™*^ 

bo u S1 v he Att ther r 1 a, :r the potentiai dan9er that data cou,d be SSS IZTTZZTeZ 

sZT™:t^:tj s : h, vr ger have invo,ved f,aggin9 certain °»* < ie,ds ^ J7£ sss 

entered ° f authenticatio " SP**" input fields, exactly as they were 

invpnZ^ * d ° e * " ot P ermit da ^ structures to be assembled and then digitally signed The present 

ena w ch^o be 1^2 ? * C ° mPUte - aCCOrdi " 9 t0 ™* a, 9 orithm 

tenal wh.ch ,s to be signed, and also, as needed, the digital material which is to be verified 

f mh JT> ♦ .? f T P 6 PreS6nt inVemi ° n a " 0WS the actual data which 'S signed to be different than anv 
f^ata .tself. «n fact, ,t ,s possible that the signed materia, contains none of the' actual diJSS^ 

^r^ 
wi,l £v I long^ 

w.ii nave a long l,fe - and perhaps be venf ,ed by different entities over a period of time In the case of EDI 
for example the s.gnatures can be bound to the EDI transaction itself, and may be verified bv antf^r f~ 

Th^can mclude .nformation contained in a user's X.500 certificate, or enhanced dig cerTific^te Je^a as 

program '"'"mat.on can even be used to regulate the future transmission route for the travelling 

reaulrem d e d n t ;r a t n 0 w ,JSin9 S, ' 9natUreS Simp ' e authenti <*t'°n. the present invention also allows authority 
SZ^^^^ - example, the teachings of 

to tor e ^'J h - e . T"' 'T 000 " 3,30 a " 0WS US6S digital si 9 natures 10 al,ow ^ ^veiling program 

be changed once the receiving user has taken any action at a... This second type of JS^S^£ 
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primarily seen as a protection against tampering, and can also be used forensically as a backward audit to de- 
tect unauthorized tampering even by one of the actual users of the form. 

In addition, the present invention also provides a third type of authentication, whereby the travelling pro- 
5 gram itself may be signed, authenticated and authorized by some trusted issuing authority (e.g., perhaps the 
author), to insure that no bugs or "viruses" have been introduced. (This even protects against infection by a 
user which has valid possession of the program along the route). 

The present invention provides a unique mechanism for automating data collection among a group of users. 
The travelling program may be sent to one user, attach (or detach) relevant data files and move on to the next 
10 user. Data or files, collected from one or more users can be deposited with another user, or accumulated for 
batched processing as desired. This methodology eliminates the need for individual users to be counted on 
to transmit all the required data in the required format 

The present invention also efficiently performs electronic document interchange (EDI) in the context of a 
travelling program which sends itself from user to to the next within an organization, collecting, editing and ap- 
15 proving data. At the appropriate point, as determined by the program's logic, it is then able to programmatically 
generate a standard EDI transaction (e.g., such as the X12 850 Purchase Order transaction set) for transmis- 
sion to another organization. The travelling program is able to digitally sign the finished transaction set. Ac- 
cordingly, any receiving organization which can process the standardized EDI, and the standardized signature 
will be able to authenticate and process the incoming material, even if the receiving organization does not have 
20 all the powerful techniques available which are taught by the present invention. 

Conversely, the present invention allows a travelling program to receive ordinary EDI transaction, possibly 
signed, and allows them to be parsed and incorporated into its variables. The travelling program then has the 
capability of validating the input and incorporating them into displays, and to move them among various reci- 
pients as necessary. 

25 According to a first aspect of this invention, there is provided in a communications system having a plurality 

of computers coupled to a channel over which computers may exchange messages, a method for processing 
information among said computers comprising the steps of: providing a first computer with a sequence of pro- 
gram instructions which are executed by the first computer, including instructions which determine at least one 
next destination that should receive the set of instructions, said set of instructions including instructions for 

30 transmitting said instructions together with accompanying data to said next destination; computing a digital val- 
ue, the content of which is based on logical decisions and manipulations performed by said program; and per- 
forming a digital signature on said digital value at at least one destination. 

According to a second aspect of the invention, there is provided in a communications system having a plur- 
ality of computers coupled to a channel over which computers may exchange messages, a method for proc- 

35 essing information among said computers comprising the steps of: providing a first computer with a sequence 
of instructions which are executed by the first computer, including instructions which determine at least one 
next destination that should receive the set of instructions, said set of instructions including instructions for 
transmitting said instructions together with accompanying data to said next destination; acquiring data from 
users of at least one of said computers via execution of said instructions; translating said data via the executing 

40 of said instructions into a specialized data structure conforming at least in part to a recognized standard where- 
by said data structure is useful independently of said instructions; and digitally signing said data structure via 
the execution of said instructions. 

According to a third aspect of this invention, there is provided in a communications system having a plur- 
ality of computers coupled to a channel over which computers may exchange messages, a method for proc- 

45 essing information among said computers comprising the steps of: providing a computer with a first travelling 
program comprising a sequence of instructions which determine at least one next destination that should re- 
ceive the set of instructions, said set of instructions including instructions for transmitting said instructions to- 
gether with accompanying data to said next destination; providing at least one of said computers with a second 
travelling program; executing the second travelling program under direction of the first travelling program. 

so According to a fourth aspect of this invention, there is provided in a communications system having a plur- 

ality of computers coupled to a channel over which computers may exchange messages, a method for proc- 
essing information among said computers comprising the steps of: providing a computer with a first travelling 
program instance comprising a sequence of instructions which are executed by the computer, including instruc- 
tions which determine at least one next destination that should receive the set of instructions, said set of in- 

55 structions including instructions for transmitting said instructions together with accompanying data to said next 
destination; providing at least one of said computers with a second travelling program instance; processing 
the second travelling program under direction of instructions in the first travelling program instance. 

According to a fifth aspect of this invention, there is provided in a communications system having a plurality 
of computers coupled to a channel over which computers may exchange messages, a method for processing 

3 
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BRIEF DESCRIPTION OF THE DRAWINGS 

3?£ p E reUn, a int^ 9ram ^ 3 COmmu " iCa « 0 "^ m in accordance with an exemp.ary embodiment 

FIGURE 3 fhowJ "STE? T ° fat ™° ™™ Aether with its associated components; 
c X 1 u ex e"iPlary execution control area data structure; 

FIGURE I ^tmlT^^ 0 "* 01 6I °'* iS U, " ized ,h * exeeuU <»" °< a ^»«"9 P«gw 

; ssr is^rssssr sr (VC8 > ** h Is - 9 — 

FIGURE 8 shows how the header is loaded; 
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FIGURE 9 shows how the "program" segment of the travelling program is loaded; 

FIGURE 10 shows how the "variables" segment of the travelling program is loaded; 

FIGURE 11 shows how the "certificate" segment of the travelling program is loaded; 
5 FIGURE 12 shows how the "file" segment of the travelling program is loaded; 

FIGURE 13 delineates how the "closure" segment of the travelling program is loaded; 

FIGURE 14 represents the operations performed in processing P-code instructions; 

FIGURE 15 shows processing which takes place after the P-code operation is performed; 

FIGURES 16A and 16B show processing for handling program defined functions or calls; 
w FIGURE 17 shows the sequence of operations for handling built-in functions; 

FIGURES 18 and 19 delineate the sequence of operations performed for executing external functions or 

calls; 

FIGURES 20 and 21 delineate the operations which are performed when a travelling program mails itself 
to a predetermined recipient; 
15 FIGURE 22 delineates the sequence of operations for attaching a file to the travelling program; 

FIGURE 23 shows how a file may be erased from a user's system; 

FIGURE 24 shows the sequence of operations performed in detaching a file from a travelling program; 
FIGURE 25 delineates the sequence of operations performed when a file has been transformed into a 
user file; 

20 FIGURE 26 delineates the sequence of operation performed when material is to be digitally signed; 

FIGURE 27 delineate the sequence of operation performed by a "INTER-ROLLOUT" function; 

FIGURE 28 shows the sequence of operations performed when displaying information to the user; 

FIGURE 29 delineates the sequence of operation performed by the "time delay" routine; 

FIGURE 30 shows the sequence of operations for a "select from directory" function; 
25 FIGURE 31 is a routine which demonstrates how the the interpreter program permits a user to perform 

digital signatures; 

FIGURE 32 exemplifies how a user verifies received information; 

FIGURE 33 illustrates how a travelling program collects a file to be transferred; 

FIGURE 34 illustrates the travelling program operations performed in reading data from a specified file; 
30 FIGURE 35 illustrates how the travelling program may update or create a file from program variables; 

FIGURE 36 illustrates how a travelling program may be designed to be split and send programs to a number 
of different recipients; 

FIGURE 37 demonstrates how previously split programs may be merged; 

FIGURE 38 shows an alternative approach to mergjng previously split travelling program information; 
35 FIGURE 39 is a flowchart indicating how the travelling program has been designed to accommodate elec- 

tronic document interchange generation functions; and 

FIGURE 40 relates to the use of travelling program in receiving an electronic data interchange transaction. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

40 

Figure 1 shows a block diagram showing an exemplary communication system which may be used in con- 
junction with the present invention. This system includes a communication channel 12 over which communi- 
cation between terminals A, B,..N, may take place. Communication channel 12 may, for example, be an un- 
secured communications channel such as a telephone line. 

45 Terminals, A. B, ...N may, by way of example only, be IBM PC compatible computers, having a processor 

(with main memory) which is coupled to a conventional keyboard/CRT display 4. The processor with main mem- 
ory 2 is also coupled to a non-volatile storage which may be a disk memory. Each terminal, A, B...N also in- 
cludes a conventional IBM PC communications board (not shown) which, when coupled to a conventional mo- 
dem (6, 8, 10, respectively), permits a terminal to transmit and receive messages including travelling programs. 

50 As used herein, a "travelling program" is a digital data structure which includes a sequence of instructions 

and associated data and which has the capability of determining at least one next destination or recipient for 
receiving the travelling program and for transmitting itself together with all relevant data determined by the 
program to the next recipient or destination. 

Each terminal is capable of generating a message and performing whatever digital signature operations 

55 may be required to load and execute the logic, data, and functions inherent within the travelling program (as 
described more fully herein), and transmitting the message to other terminals connected to communication 
channel 1 2 (or to a communications network (not shown) which may be connected to a communication channel 
12). 

The digital signature and certification methodology described in the inventor's U.S. Patent Nos. 4,868,877 

5 
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hlfn i h , 33 W ! 35 5, ° 01,752 may be USed herein ' which P atents ™ hereby expressly incorporated 
sZl LT^ r" 3 ^ m ° re Conventional ^nature methodology LyTuTe" ' 
Before descnb.ng the details of the "travelling program" structure and methodology in accordance with 
an illus rative embod.ment of the present invention, an example of the general operatio fn an factual business 
faction context w,l. be briefly described, .nitially, presume that the user of the Figure 1 termini A 1 a re. 

^X^^^Z^ an of a design team in 3 c — seekin9 - — « 

The engineer using keyboard 4 would access a parts requisition "travelling program" of the type to be de 
scnbed ,n deta.l below. The requisition "traveling program" will prompt the engineer^ dLnbe the componeni 

to f n r?H >* traV6l,in9 Pr09ram indUdeS a " instruction se « uence which automatic^.rtr a «se" 
Lai J e " 9 - 10 3 SUP6rViS0r Wh ° haS 3CCeSS t0 terminal B and -ho is higher u^ in STSS 

eZ nrnnrf 6 ' FT"" aUth ° rity * ' ppmve the re « uisition re " uest a "« digitally signTt The ^v- 
enmg p ogram may also transmit ancillary information, such as f fles which may be necessary or useful at fu^re 
dest.nat.ons The supervisor will be prompted to properly digitally sign the request It is possible^ the di5 

27T "?? " 0t ° n,y SP6CifiC Variabl6S Valu6S ' but a,so the variab '* AiternaXey the * ^ 

whLtth , S ° me I": 693 ' 6 StrUCtUre WhiCh iS derived from variable * computed within he program 
1 he Inl ^ 6 b3Sed °" 3ny ° f many S0Urces ' indudin 9 data read fr ™ — inZt Si tS 
The use^r 3 "" 3 S CerWiCateS ' ° r d3ta WhiCh " eXtraCt6d fr0m the user environment (Lch as 
9nn f r ^ ue ( St is a PP^ed, the requisition form will take a different path in the organization then if it is not 
approved. The travelhng program can have the intelligence to determine, based upon the input from he su 

w r: i x ££^zr*" B> where to transmit itseif within the ° r9anizati ° n - 

will also, if desired load the memory associated with terminal B with the appropriate data relatina to the reaui- 

Once T ? ' 1168 fTOm lermina ' 8 1 hat ne6dS to be forwarded'elsewhe 3 ^ tZ 

for an ™ T ^ *' traVe " ing Pr09ram haS ,he abi,ity at an * ,ater tima - any later user' 

"^SL of r S^-' n ? materi ? t0 ^ Venfiedl 3nd t0 P6rf0rm 3 di9ital si ° nature verification " 
r-„ liL \ < verrf.cat.on can be announced to any recipient, or more likely, the travellinq proaram 

and announce a problem shou,d there be a failure < which aZ a pT 

sibl p B f^h,! he \ raVe ! lin9 , Pr< L 9r3m m ° nit0r may emb0dy the teachin 9 s of 4.868.877 and 5.005.200 it is pos- 
tiofs SCSS l ° a,S ° ^ Ch6Ck6d S ° that 3ny reCipient « be — d < ba < «"• necessary ajhoS- 

it is Z^MeTsT^ ? rUCtUre T COnStruCted and si 9"<* «nd.r control of the tr ave „ ing program> 
SuJ TZt 1 subsequently reconstruct that data structure and to provide its signature to any other entity 
Such data can not be subsequently tampered by any entity y ' 

as it is7eTfromTru^r?H nUOn 3 ' S ° r^' 63 capability whereby all the transmitted data is digitally signed 
1 tl J < > ? t0 thS neXt " The travellin9 proaram Processor in the recipient's computer can LZ 

TaS Z1 V S ' 9 T r T thS traVe " ing Pr ° 9ram iS ,0aded " This assu "* < ba < "° comooZt whTsoevTr 
is a tered or tampered along the way. While this overall signature only reflects the state of t he data dur na thS 
part.cular transm.ss.on. and has no significance for later users, it does insure a ^rfecrfransmfesior^ untoZ 
peredbyth,rd parties, and it does provide a forensic audit mechanism if it is necessary ^ 
by par .c.pat.ng users, while those users had possession of the form. This overal. signau.rrd^rorcurnt 

XZ^^£££S££Z si9nature can be — y — »™ 

.oZ?^^:z^:ssr n obtained within the or9anizationai *° 

nnc T ,h ,S . C ° Uld ^ e d ° ne many W3yS - 11 may we " be possib,e fora travel| in9 Program to support several meth 

1^S2?n 0n * m ° St aPP T i3te f ° r 3 9iVe " drCUmS tance " We d^befour possiEs here 
1 . The traveling program could simply print out the final purchase order on paper -possibly even printino 
the company logo, letterhead, etc. - which would be physically mailed V P 9 

LtJV™ 6 !' " 9 Pr09ram, if C ° Up,ed with an outaoin 9 computer-to-fax capability, could automatically oen- 
IZI^Z " na9e ' th3t W ° U,d aPPear ° n Vend ° r ' S f3X buyer would not have 

fhe^is^ 

4 that he travelling program will simply designate the vendor as a next destination 

4 lUs also very possible that the vendor does not use the present invention, or that the purchaser's trav- 

m e rd7ogy m Cann ° l determi " e ^ the Vend0r iS able t0 handle ^ Celling progr^ 
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Therefore, the travelling program manipulates its internal data to construct a standardized EDI (Electronic 
Data Interchange) transaction, which can be widely recognized and processed. The travelling program may 
also cause a digital signature to be performed on the computer EDI transaction, and the signature and the 
5 transaction can both be transmitted. The travelling program would then transmit the EDI transaction, as well 
as any possible signature, to the recipient (Such transmission is independent of, and should not be confused 
with, the transmission of the travelling program and its ensemble from user to user as part of its directed trav- 
els.) 

Any recipient that can handle standardized EDI transactions is then able to handle the received EDI input. 

10 Any recipient that can handle digital signatures, is further able to authenticate the transaction. Furthermore, 
provided the recipient has sufficient software capability to recognize them, the recipient can also automatically 
validate any authorization that may be embodied as part of the signature. It is up to the logic of the travelling 
program the extent to which certificates should be transmitted along with a signed transaction. 

In any of the above cases, the travelling program can spin off the purchase order (P.O.) information to the 

15 vendor, using any of several possible levels of automation. Following this, the travelling program might transmit 
one version of itself, or possibly just a letter, back to the originator, to inform him that the P.O. has been sent. 
Other information can be sent to an archive, or to a queue to await further processing. This information could 
be a simple message, a record added to a file, or perhaps the travelling program schedules a full traversal 
(automatic "mailing* or transmission). 

20 Figure 2 illustrates the structure of a travelling program together with its associated components in accor- 

dance with an exemplary embodiment of the present invention. The Figure 2 travelling program includes at 
least the following multi-field segments. A first header segment 20 preferably identifies the size of each of the 
component segments, the name of the associated program (and possibly other segments described below), 
the date, the type of each component (e.g., the program is the source language program, or the program is 

25 P-code that has already been compiled), the identity of the form, version of the interpreter needed to execute 
it, data necessary to resume execution at the appropriate point of program resumption (such as execution 
stacks, PCBs, etc.), dates associated with the latest traversal, and program authorization information (PAI). 
Each segment in the travelling program structure may include its own description so that the "type of each 
component and size" field "S" would not be included in the header segment 20. For the purposes of the present 

30 application, program authorization information (PAI) may be regarded as security information which defines 
the range of operations that the associated program is permitted to perform (e.g., defining access to files, the 
ability to call programs, ability to generate electronic mail, ability to transmit data to other users, ability to , re- 
lease documents, ability to execute machine language programs, ability to access special areas of memory, 
ability to display information to users, ability to solicit digital signatures, ability to access a digital notary public 

35 device, etc.). Further details regarding the nature and use of the program authorization information may be 
found in applicants application Serial No. , entitled, "Computer 

System Method and Apparatus Using Program Authorization Information (Atty Dkt. 264-29). The header seg- 
ment 20 may also include a version number of the associated travelling program. 

The travelling program code 22 segment follows the header in the exemplary embodiment and preferably 

40 is written in the restructured external execution programming language (e.g., the REXX language) or some- 
thing akin to PASCAL or COBOL. The program itself may, for example, relate to a purchase order related ap- 
plication. 

The travelling program will possess the characteristics described above including the ability to transmit 
itself to further recipients. Thus, program 22 will include instructions for forwarding itself via whatever medium 
45 is available to one or more recipients this is known herein as a "traversal". One source code instruction or sev- 
eral P-code instructions may be required to result in the "traversal" of the travelling program to one or more 
identified recipient(s). The travelling program structure set forth in Figure 2 is designed to be independent of 
any particular computer architecture and is structured in accordance with international standards (e.g., X.209 
format). 

so The travelling program also includes a "variables segment" 24. Prior to being executed by a first user, the 

variable segment 24 may be virtually empty. Once the program is sent to a recipient, further variables will be- 
come defined as they are required by the program to thereby result in an increasing number of variables as 
the program is further executed. By way of example only, the variable section 24 may identify a variable, such 
as "total, do liars, received" together with an actual data value for this variable. 

55 Each variable may have associated therewith the information set forth in each of the fields 32-42 shown 

in Figure 2. Field 32 identifies the size of the variable name. The variable name itself is stored in field 34. The 
size of the value of the variable is set forth infield 36. The value of the variable is in field 38. Field 40 identifies 
the execution stack level to which the variable belongs. The execution stack level is identified since the same 
variable name can exist at different levels within a program (e.g., one variable name may exist in a first sub- 

7 
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oriented or record oriented. Other attributes of the file may be defined in this field. 

Segment 114 stores an indication as to the file's position within the main incoming travelling program file 
so that the particular file in question may be quickly accessed. Segment 118 identifies whether the local name 

5 of the file (i.e., the file name identified by the most recent recipient of the travelling program). The local name 
of the file is typically provided if the file has been attached and is being forwarded to a further recipient or if 
an already attached file is being "exported", i.e., stored locally by a particular user. Additionally, as shown in 
Figure 4, the FCB may contain a hash of the associated file. As will be appreciated by those skilled in art, a 
hash is a "one way" function which should be computationally easy to compute given the underlying data. The 

w hash function should be computationally impossible given a hash value, to either determine the underlying 
data, or to create any data which has the specified value as its hash. For all practical purposes, the value ob- 
tained from applying a hashing function to the original aggregation of data is an unforgeable unique fingerprint 
of the original data. If the original data is changed in any manner, the hash of such modified data will be dif- 
ferent. 

15 Figure 5 shows an exemplary program control block that may be used during the execution of the travelling 

program. A program control block keeps track of control information regarding the program being executed in 
a structured programming context where one routine calls another routine, each routine having an associated 
program control block. 

The program control block segment 50 points to the prior program control block in the program execution 

20 control stack. The program control block includes a segment 52 which defines the next P-code position to be 
executed in the current executing program and segment 54 defines the type of last P-code operation per- 
formed. Segment 56 includes a pointer to an expression evaluation stack which is used during expression eval- 
uation. The execution stack is typically distinct from the program stack, in that the execution stack is used for 
evaluating expressions and keeping track of internal state. Segment 58 defines the level of this stacking pro- 

25 gram and segment 60 defines a pointer to a list of shared variables. In the REXX language an "exposed" state- 
ment may be used for accessing shared variables. 

Figure 6 illustrates a variable control block data structure (VCB) which is used for controlling variables. 
Segment 62 identifies where in the B-tree a variable is located and may contain several pointers. Segment 64 
identifies the size of the variable value and segment 66 identifies a pointer to where the value is located in 

30 memory. Segment 68 may be optionally used to identify the type of variable. Segment 70 identifies which level 
of the travelling program the variable is associated with, so that after the program is executed, any local va- 
riable which was associated with the program may be readily deleted. Segments 76 and 80 identify the size 
of the variable name and the name, respectively. 

We now turn to illustrating the execution of the travelling program. The sequence of operations performed 

35 by a "loader" portion of an interpreter execution-driving program is set forth in Figures 7-12. These operations 
relate to preparing to execute a travelling program, 

A travelling program may execute in one of a plurality of different modes such as an interactive user mode, 
a mode in which it is called by another program, or a batch operation mode in which it is sent from node to 
node collecting information. Initialization information is input during the start-up operation (120) to identify the 

40 particular operating mode as well as associated run-time parameters. 

The flowcharts set forth in Figures 7-12 illustrate how a travelling program structure shown in Figure 2 is 
loaded. In loading the travelling program, the interpreter creates the execution control area XCAand initial pro- 
gram control block PCB. It saves access to input parameters, saves the names of the input files that it has 
been given to load and initializes the variable information table (VIT) (122). In flowchart block 122, the exe- 

45 cution control area and program control block associated with the travelling program are established. The va- 
rious XCAand PCB fields are filled in during subsequent processing. 

Thereafter, the loader begins loading travelling program segments, i.e., header, program, variables, cer- 
tificates, file and closure segments as shown in Figure 2. Loading each of the travelling program segments 
described above, e.g., header program, etc., causes appropriate data to be filled in as described below. 

so in block 124, a decision is made as to whether more segments need to be processed. If so, then the initial 

input is read for that segment and the type of segment is'deter mined after which segment processing is initiated 
depending upon the type of segment (126). 

Turning to the header processing of Figure 8, initially, a check is made to determine whether the segment 
being processed is the first segment (150). If not, then an error condition exists (152) since the header must 

55 be the first segment. If the first segment is being processed, then the header is read and hashed. The header 
data is stored into the XCA (154). 

The routine then branches back to Figure 7 at entry point L. The loader determines whether there are any 
more segments to be processed (124). If so, block 126 is executed to result in the processing of the "program" 
segment as shown in Figure 9. Initially, a check is made to determine whether there is a header, and no program 
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If there ,s a match, a check is made as to whether the travelling program is signed (236). If not, then as 
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suggested at block 238, an action is taken to incorporate whatever level of security is desired, such as possibly 
presenting a notification that the transmission data is not entirely signed (238). 

If the transmission was signed, then the signature is verified and a message is presented to the user to 
5 accurately identify the party who actually sent the travelling program (and the associated purchase order or 
other form) 240. The routine then branches back to block 124 of Figure 7. 

The completion of the "closure" processing in Figure 13 results in block 124 determining that there are 
not more segments to be processed. Thereafter, a check is made to determine whether closure was success- 
fully received and processed (128). If it was not, then the routine stops execution after performing an unsuc- 
10 cessful validity check (130) and processing halts 132. 

If the check at block 128 reveals that closure was successfully completed, then various steps are taken 
to prepare for program execution (134). In this regard, stacks are restored, the variable information table and 
variable control blocks are restored. The program control blocks are restored such that they contain the exe- 
cution resumption point. 

15 Thereafter, the routine shown in Figure 14 is initiated to actually process the P-code instructions. The fol- 

lowing problem must be considered here. Because the program execution is effectively restored identically to 
the state it was at the time it was transmitted (as part of the traversal) from the sender's machine, there is an 
issue of how the travelling program can distinguish whether it is in the sending machine, and just returned from 
the sending itself; or whether it has just been restored in the recipient machine. 

20 The present invention allows multiple ways to address this problem. If the traversal function is implemented 

as a built-in function, then the interpreter will return a special value (say "0") to the program after it has suc- 
cessfully sent itself, and another value (say "1") to the program when its execution is restored on the recipient's 
machine. The travelling program can then test this value to distinguish the situation. Another way this distinc- 
tion could be made is by providing the travelling program a function to extract the "number of prior traversals" 

25 (segment 98 in the XCA). Before invoking the traversal, the program could use this function to save the prior- 
traversal-count function. If it matches the value of the variable, then the program knows the execution is re- 
suming in the sender's computer if it differs (and it should only be one greater), then the program knows the 
execution is resuming at the recipient's computer. 

When the first user generates the travelling program, the loader routine shown in Figure 7-13 is executed 

30 with very few, perhaps no, variables, files, or certificates. Accordingly, certain of the above-described steps 
will be omitted during the initial processing. The loader routine is executed whether the travelling program is 
executed for the first time or executed by further recipients. 

Figure 14 illustrates the operations performed in processing P-code instructions; it is repeated for every 
P-code instruction executed. As indicated in block 250, the location of the next P-code instruction is derived 

35 from the current PCB (52), and this becomes the "current" P-code operation. In block 252, the length of this 
P-code operation is determined, and the "next P-code" position (52) is updated to reflect the subsequent P- 
code instruction. The type of the current P-code operation is saved in (54) (It is useful for the interpreter to 
share common routines which have slight variations based on the precise operation. For example, the "call" 
operation and the "function invocation" operation are similar except that the function invocation expects a para- 

40 meter to be returned). 

Thereafter, as illustrated in block 254, the indicated P-code operation is performed. Most P-code functions 
involve data manipulation, logical tests and program flow control. By way of example only, such P-code oper- 
ations may include locating a variable and pushing the variable in a stack, resetting the next P-code operation 
to thereby change the flow of control such as would occur in a branching operation, performing an arithmetic 

45 or string operation, performing IF/THEN/ELSE operation based on the popped stack value, perform DO/ITER- 
ATE/UNTIL/WHILE, or other operations based on stack values, performing SELECT/ WHEN/OTHERWISE op- 
erations based on the stack values, performing an "END" operation to close a DO/WHEN/SELECT operation. 

We will soon discuss in some detail various P-code operations pertinent to the present invention's unique 
operation. With the guidance given herein, the P-code functions can be implemented in a straight-forward man- 

50 ner by anyone familiar with writing interpreters. 

However, ignoring for the moment the details of the particular P-code function, the preferred design allows 
for P-code operations to generate logical "interrupts" at their completion. 

These allow processing P-code processing to be suspended while some other, external operation must 
be performed. This interrupt concept is used in the preferred design to facilitate the rollout of working storage 

55 whenever lengthy waits or external activity is invoked. 

In Figure 15, on return from the P-code routine in block 256, the interpreter determines whether the routine 
has signaled a logical interrupt. If not, then return is made to 250 to handle the next P-code operation. 

If an interrupt was indicated, a special check in block 258 is made to determine whether this is the special 
"EXIT" request. If so, then all resources which should be released at the end of this program, such as storage. 
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to wa unt,l a future time or other event, or to invoke another program which might wrt^^oTSTSi 
delays, or require a large of storage which is vacated by the ROLLOUT. 
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the execution stack in and only in the case of a function. For example, the SIGN function returns a value which 
represents the digital signature computed on the supplied data. 

In Figure 16Awe see that a call/function to a program routine causes the creation of a new PCB execution 
5 level 300. The new PCB is set to start executing at the start of the subroutine, by setting the next-P-code in- 
struction (52) to the P-code entry point of the routine. The first instruction of the routine will be accessed when 
block 250 is reentered. Parameters are prepared for the program routine, appropriate status condition are set, 
the program level 58 in the PCB is set to one higher than the calling program and the PCB is placed at the 
top of the execution stack as the now current PCB (82). The result of a program routine is passed to the caller 
w through the P-code RETURN operation. 

In Figure 16B, we see how the corresponding program RETURN P-code operation operates. Block 1200 
determines if a RETURN is made from the highest (only) level PCB, in which case this operates as an EXIT, 
and block 1204 signals that a P-code "EXIT* interrupt is required and passes the return RESULT (if any) as 
the value to eventually be returned by block 261 (Fig. 15) as the RESULT for the entire program. 
is Otherwise, in block 1204, determination is made as to whether the invoker used a CALL or function (e.g., 

by checking field 54 in the caller's PCB), and in the latter case block 1206 puts the return VALUE on the stack 
(or creates a default value if the RETURN had no operand). 

In block 1208, the current level is cleaned-up, and all resources, including storage, files, variables, etc pri- 
vate to this subroutine (aka "program level") are released. Resources, such as variables which are shared with 
20 the caller are NOT released arid are available. 

In block 1210, the current PCB is then released so that the caller's PCB now becomes the current one, 
and return is made to block 256 where execution resumes. 

The interpreter includes built in routines which are designed to accomplish specialized travelling program 
related functions relating to providing digital signatures, user files to the travelling program and other functions 
25 to eliminate the need for a travelling program designer to be concerned with programming such functions. 

P-code operations may also involve the performance of a RETURN function which will affect program con- 
trol, a PROC operation which relates to a program control block, The interpreter also performs a DISPLAY op- 
eration which utilizes the interactive display methodology/language described herein. The interpreter also per- 
forms a TRAVERSE operation which results in the "mailing" of the travelling program to another recipient as 
30 well as all associated data. 

Figure 18 illustrates an exemplary the sequence of operations performed for executing external functions 
or calls. Such external functions or calls are not built in to the interpreter or part of the travelling program but 
rather are part of the user's program library. The named function or call is located from any of several possible 
libraries 354. 

35 A check is then made to determine if the program is found 356. If the program is not found, then a check 

may, if desired, be made to determine whether the program should be terminated or some default action be 
performed 358. If a decision is made to terminate, then an error message is generated, and after various 
housekeeping/cleanup operations are performed as described above the program is exited (360, 362). 

If the check at block 358 indicates that a default action should be taken, then the default action is taken, 

40 e.g., by returning a special default function value (368) and the routine branches back to node 0 in Figure 14 
to begin executing further P-code instructions. 

If the program is found as a result of the check made in block 356, then parameters are constructed by 
the program (364). Invoking external routines involves a P-code interrupt, with a possible rollout. This allows 
us to conserve storage in multi-user swapping environments if the external program is lengthy, or in any en- 

45 vironment if the external routine is huge and therefore the storage used by the travelling program should be 
vacated in order to satisfactorily perform the external program. In this case, the P-code interrupt is signaled 
in block 366. The indicated PRE-ROLLOUT routine copies the parameters to the external form the stack (or 
variables) to temporary storage. The INTER-ROLLOUT routine invokes the EXTERNAL routine and receives 
any returned result; and the POST-WAIT routine copies the returned result to the stack (if the external routine 

so was invoked as a function). 

It is possible that the external routine is actually another travelling program. If so, then special optimization 
may be performed by using the existing already-loaded image of the P-code interpreter, and simply passing 
a new set of parameters to block 120 (Fig. 7). In this, special logic would need to be inserted in blocks 262 
and 264 to conditionally avoid releasing the interpreter code itself. 

55 Now let us turn out attention to various special built-in functions which are used by the present embodiment. 

Many of these could be executed either as built-in functions, or as language statements with their own special 
P-code operation. 

Figures 20 and 21 illustrate the operations which are performed when a travelling program transmits itself 
to a predetermined recipient. In block 398, any program authorizing information is first checked to insure that 
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icate segment, should be included in the CLOSURE segment. Thereafter, the transmission is dosed 436. 

Finally, in block 437, the value "1" which was previously loaded onto the execution stack for the benefit 
of the transmitted program when it arrives at the recipient, is removed and replaced with the value "0" — which 
5 is returned to the current caller to allow it to distinguish itself. 

Because creating a digital signature typically involves user interaction — such as possibly selecting a cer- 
tificate and opening the private key, or asking the user to operate his digital signature token device - the ma- 
terial described in Figure 20 and 21 will actually operate in the preferred embodiment as P-code interrupt rou- 
tines. As an example, the TRAVERSE function code would trigger a P-code interrupt, in which the logic from 
w blocks 399 to 430 would operate as a PRE-ROLLOUT routine, while the block at 432 might operate as a INTER- 
ROLLOUT routine since it may require the aforementioned user interaction. The blocks thereafter (434, etc) 
would operate as a POST-WAIT routine. 

The travelling program can be designed as desired to transmit itself numerous time during its execution to 
various recipients. In such multiple transmissions, the variables can be changed prior to each transmission as 
15 appropriate. In this fashion, the program in the position to do processing distinct for each recipient in a manner 
which is implementation dependent. 

Figure 22 illustrates a sequence of operations for attaching a file to the travelling program. The attach file 
routine responds to an identified file tag and an identified file name. As indicated at block 440, a check is made 
to determine whether a file control block with the same tag exists. If so, then the previous file with the same 
20 tag is deleted 442. 

Thereafter, a check is made to determine whether the specified file name reflects an existing file which 
is accessible by the user. In this regard, the travelling program may be associated with program authorization 
information which defines the range of operations which the program is able to perform, including the ability 
to access files. Such program authorization information will be checked to determine whether the file name 
25 is accessible. If the file name is not accessible by the user, then an error code/message is returned to the 
user 446. 

If the file name is accessible to the user, then a file control block (FCB) is built with the specified tag and 
file name and the file will be attached during the next and subsequent transmission of the travelling program 
448. The routine is thereafter resumed with an indication that the file has been attached successfully. 

30 Figure 23 illustrates how a file is erased from the user system. When an "erase" function is attempted to 

be executed, security codes are checked to determine whether the program is authorized to perform such an 
operation (450). If the security codes indicate that the program is authorized to erase the specified file (452), 
then an erase operation is performed and the routine branches back with an indication whether the file was 
successfully erased 454. Alternatively, if the program is not authorized to perform an erase operation, then 

35 the calling routine is returned with an error message indicating that the file could not be erased (456). 

Figure 24 illustrates the sequence of operations performed in detaching a file from a travelling program. 
As indicated in block 458, a check is made to determine whether a file control block exists for the identified 
tag associated with the file to be detached. If no FCB exists, then the main routine is returned to with an error 
message indicating that the file could not be detached 462. If the file control block does exist as determined 

40 at 458, then the file control block is deleted at 460 and the main routine is returned to with an indication that 
the file has been successfully detached. 

Figure 25 delineates the sequence of operations performed when a file is to be "exported", i.e., trans- 
formed into a user file. A travelling program may take a specified file, for example, representing a spreadsheet 
and convert such a file to a recipient user's file that remains with the user even after the travelling program 

45 has been sent to a further destination. The file to be "exported" will be identified by a tag and an output file 
name and, if desired, a rewrite indicator identifying whether the file may be rewritten. 

A check is initially made as to whether a file control block exists for the specified tag 498. If no FCB exists, 
then an appropriate error indicating code is generated and the calling routine is returned to (504). If a FCB 
does exist with the specified tag, a check is made to determine whether the file is part of an incoming travelling 

so program 500. If the file to be exported was not part of an incoming traversal, then it must have been attached 
by the user and already be present in the user's file and, accordingly an error message is generated indicating 
that one is not allowed to export a newly attached file 502. If the file was part of the incoming traversal, then 
a check is made to determine whether the specified file already exists (480). If so, then a check is made at 
block 482 to determine whether it is okay to rewrite the specified file. The check includes determining whether 

55 the program is allowed to modify the specified existing file (if no "overwriting"), or to erase and create the spe- 
cified file (if "overwriting" is permitted). If not, then the block 484 is used to return an access error to the pro- 
gram. If the check at 482 indicates that it is okay to rewrite, a determination is made as to whether the file 
should be overwritten or whether new material should be added to the end of the file (486). If overwriting is 
indicated at 486, then the existing file is erased (488). A new file is created, if permitted by program authorizing 
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security information and preparations are made to start writing at the beginning of the file (490) 

Figure 26 illustrates an exemplary sequence of operation performed when material is to be dioitallv 
In implement the digital signature function, initially a check is made to determ EwSS£ SZ£ 
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underlining, blinking, reverse video, non-display (e.g., for hiding passwords), high intensity display, etc. Addi- 
tionally, possible error messages are inserted where appropriate for a detected error condition and the proper 
cursor position is indicated. 

5 The layout language used in block 540 permits not only the definition of a screen output but also definitions 

for accepting input. As indicated in block 542, fields are written to the user's terminal allowing input fields, as 
appropriate depending upon the application. As previously described, data structures may be rolled out to aux- 
iliary storage (544) and rolled back (546) after the user performs data entry into the appropriate input fields. 
To do this, the step 544 actually involves signaling a P-code interrupt, and having the block 545 executed 

w as the associated INTER-ROLLOUT routine, and block 546 executed as the POST-WAIT routine responsible 
for mapping the input fields back to the VCBs for the associated variables. This may involve passing data 
through temporary storage. 

Thereafter, the input is analyzed and the input data is inserted in all associated variables. Afield validation 
is then performed for all input fields 548. Thus, a check may be made to make sure that for numeric fields 

15 only numbers have been entered. Similarly, a check may be made to determine whether an input field has the 
specified attributes. 

Thereafter, a check is made at block 550 to determine whether there has been an error in any field. If 
there has been an error, then an error message is produced and the cursor is positioned to the errant field 
(552), after which the routine branches back to 540 to generate an error message display. 

20 If the check at 550 fails to reveal an error in a particular field, then a further check is performed to cross 

verify that the fields are correct in context (e.g., although two adjacent fields may be correct individually, an 
error condition may be defined regarding the combination of fields) 554. Based on a cross verification, a de- 
termination is made as to whether the field contains an contextual error. If not, then a return is made to the 
caller 558. If there is a contextual error then an error, message is produced in accordance with block 552. 

25 It should be noted that verification of both the individual fields is completely under control of the program. 

There may be various specifications, utility routines and other conveniences to simplifying handling common 
situations, but in general, any possible validation is possible. Cross-validation of fields may involve more se- 
mantic concerns, and is thus more likely to require specialized programming. 

Figure 29 delineates a sequence of operation performed by a time delay routine. The time delay function 

30 may be utilized to wake up at predetermined time intervals and check to see whether any incoming electronic 
mail has arrived and attach itself to thatmail tothereby efficiently handle incoming electronic data interchange. 
Thus, though such a time delay mechanism, a travelling program could examine a particular mail box at pre- 
determined time intervals to check whether any mail has arrived. If the mail has arrived, the travelling program 
could send the mail to a destination to be handled by a further recipient. Alternatively, the travelling program 

35 could examine incoming data (such as mail), and based on various content indicators, automatically perform 
a traverse and spawn a new "instance" of itself which could treat the mail appropriately. Of course, the original 
"instance" could continue executing and process every instance that arrives. 

For example, if the incoming information happened to be EDI transactions, then a travelling program could 
read the information (using, for example, a READ built-in function), break it apart into internal variables, de- 

40 termine by whom it should be processed, and perform the appropriate traversal. Once successfully routed, 
the letter could be disposed, moved or archived, the program could clear its variables, and resume looking for 
more input. 

Alternatively, after determining the type of material arrived, it could invoke another program to process 
the incoming data. If the other program happened to be a travelling program, then that program could be given 
45 the necessary input information, and could then TRAVERSE itself appropriate to the handling. 

This would allow, for example, one travelling program to act as a automatic router for incoming data, such 
as EDI transactions, and then hand off to other travelling programs the transactions which it is not prepared 
to handle itself. 

Furthermore, if the EDI were signed, then the travelling program could verify the signature immediately. 
so If the signature were valid, and especially if it were done according to U.S. Patent No. 5,005,200, then the au- 
thorization for the content could be programmatically screened, and the travelling program could automatically 
spin-off an instance to handle the incoming transaction. 

For example, with proper enhanced authorization, an incoming Purchase Order could be automatically and 
instantly routed to the shipping department to commence filling. 
55 Items which arrived which were not signed, or which used simple signatures rather than authorizing sig- 

natures, could be routed to various clerical persons for exception processing and more detailed inspection. 

As indicated in block 570, the time delay routine, sets the system alarm clock for a specified time. There- 
after, an optional roll out of data to auxiliary storage may be performed (572) by scheduling a P-code interrupt 
with appropriate routines followed by a performance of a roll-in of data after the specified time period has 
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elapsed. Thereafter, a return to the calling routine occurs (576) 

Hems, either as a function result or a set of special variables (584) selected 
Again, as described elsewhere, the actual WAIT is performed through the use of the P-code internet f„nr 

ary). Appropriate information is displayed to the user (602). The user then deddes whe hi" HJT „ 

to determine whether ,t is necessary to have user interaction in order to determine the file (622nf vesTn 

anoiied !t tl f ( alte ; at,on - da ™9e or disclosure is subject to security controls. Such controls can be 

* theTgSm ^ ^ ^ traVeHin9 P ^ C0Uld »" - write user's data fi.es 

Security constraints exist for at least the following classes of functions- 
Display data to the user. 
Soliciting input from the user. 
Performing digital signatures. 
Reading data from user files. 
Creating user files. 
Erasing user files. 
Writing data into user files. 
Remaining user files. 
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Attaching user files. 
Exporting attached files into user files. 
Invoking an digital notary device. 
5 Receiving incoming electronic mail 

Reading the contents of electronic mail 
Moving or archiving incoming mail 
Deleting incoming mail. 

Generating outbound electronic mail, or doing various types of data transmissions 
10 Being coupled to various types of equipment, device and services (FAX, printers, office equipment, robot 

devices, manufacturing equipment, etc.) 
Performing a program traversal. 
Invoking external programs. 

Accessing, updating, activating, erasing, altering, invoking, or attaching other travelling programs 

15 Figure 36 is illustrates how a travelling program may be designed to be split and sent to a number of different 

recipients and Figure 37 demonstrates how the previously split programs may be merged. 

Turning first to Figure 36, the travelling program may need to be split in order, for example, to acquire sur- 
vey data from a number of different recipients or to collect or distribute data to a number of different executives 
in an organization. Initially, the travelling program performs various housekeeping operations to prepare to split 

20 650. Thereafter, variables are set in accordance with particular application requirements, e.g., the survey run 
by a particular user 652. Destination users are then determined and the traverse function is invoked as per 
Figures 20 and 21 to transmit the image of the programs, the programs variables together with any other ap- 
propriate data tailored to the individual recipients 654. The transmitted variables may change from instance 1 
(656) to instance 2 (658), instance 3 (660), to instance N (662). 

25 A check is ultimately made to determine whether there are more destinations to which to transmit (664). 

If so, then the routine branches back to 652 to transmit to the further destination. If there are no further des- 
tinations, then the final transfer is performed 666 in the same manner as explained above with respect to 654 
to result in the final "instance" 668, thereafter resulting in the completion of the splitting operation. 

In other examples, it may also be that the master program simply goes into some other processing. Per- 

30 haps, if it were running in a batch environment as an input distributor, and all the input were presently exhausted 
(having just been spun off to a number of users), it would go into a delay until something else arrived. 

Turning to the Figure 37 merge operation, the travelling program has the intelligence to transfer itself from 
user to user to merge further data until the merging operation is complete. Initially, the travelling program ar- 
rives at a merging destination and is executed (680). A check is made to determine whether this is a master 

35 "instance" which is determined by a predetermined variable being set. If it is determined that this is not a master 
instance at 682, a slave instance is identified 684. At (685) the slave program checks if it has been invoked 
with the special "DEBRIEF" parameter (which is simply a convention used by this program ot determine when 
the slave is being called by the master), and if so (687) passes back all pertinent information to the master 
instance, then exits. If this is not the DEBRIEF invocation, then a check is made to determine whether the 

40 master instance is available, i.e., has already arrived, 686. If the master instance is available then a call is 
made to the master instance 696, through the use of the call shown in Figure 18. After the master instance 
has been invoked, the routine branches back to block 680. If the master is not available, a message is issued 
that the master control for the series has not arrived 688. 

Presuming the master instance has arrived and has been invoked, then at block 682 a determination is 

45 made that this is the master instance and a check will be made to determine whether any other slave instances 
have arrived 692. If so, then the slave instance will be invoked with a predetermined parameter to initiate the 
collection of data (referred to perhaps as "debriefing") 694. At entry point E, data is collected from the instance 
and is returned to the master and is written to a collection file 706. Thereafter, the instance that has just been 
invoked is erased 708 and the routine branches back to 692 in which case further information is collected if 

50 other instances have arrived. 

If no further instances have arrived the file is checked to see if all instances have all arrived (698). If they 
have, as determined at 700, then the data could be read from the collection into variables in the travelling pro- 
gram. Depending on the expected size of the collection file, and the nature of the processing, it might be more 
desirable for the master program to process the completed file at that moment and either traverse itself to the 

55 next destination, or to encapsulate the result into a simple message, perhaps even an EDI transaction and 
simply transmit that raw data. 

In other cases it might be appropriate for the program to ATTACH the file to itself and transfer it wholesale 
to another process. The file is erased and aggregate data is transmitted to the next destination 704. If all in- 
stances have not yet arrived, then a message is issued such as "waiting for forms to arrive" (702) and the 
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routine is temporarily existed. 

s^Xl^Tw^e^T" aPPr ° aCh 10 mer9i " 9 PreV,0lJS,y Sp,it trave " in 9 program inf0 — "on- As 
snown in block 710. the travell.ng program arrives at a merging destination and is run. The collected data is 

ndicaTId J 7i/ r C,a ' h f ^ I' 2 ' A Ch6Ck " made t0 det6rmine whethe ' a » «"« instances hav arrived as 
^a«on 718 Il tH V . th8 C0 " eCted data " Pr0C6SSed 716 - and ,he program ^verses to the nextls 
IZl h dilnia h T f eX ' ted - " a " 0ther inSta " CeS have not arrived as determined at 714, then a mes- 
the^t^elT " ** f ° rmS t0 ^ ^ C ^ instanca is dieted 722 and 

Figure 39 is a flowchart indicating how the travelling program has been designed to accommodate elec 

nSL a th ^tenst.c may be used. The X12 standard has an associated data dictionary and seamen 
d.cfonary. The X12 segment dictionary, for example, may be used to define all segments necessary to 'Kfne 

IZTtl ' !f 9ment " def ' ned 33 b6ing 3 Piece of data wni <* * th." 'oote^ ^ u P Ta d'Sonary 
Because there are many d.fferent ways to specif y the quantity of an item, many variations of i «l£rS 

ft ,n ZT IT? s f J 6 ™ embeds tne X12 data dictionary into the interpreter which may be called as a built-in 

S Ens ' TheT' 3 * * X12 SUbr ° Utine by Spec * ying a 

om JS ■ - P 9ram 03,1 prOV,de X12 data °° de for P°P ular ommon options typical in the 

orgamzafon s envronment, so as to build a short list of options in order of norma, usage Examples of such 

r^aST context item number> part number and quantity - This — ™ 

A check is ; made to determine whether the shortlist is empty (as indicated in 724). If so the segment name 

aS^itS a Thereafte '' XI2 °ATANAME bu.lt-.n function would be used to expand the data dictionary each 
assoc.ated description data 738 and the long complete list would be displayed 740 a ' ct ">nary each 

If the check at 724 indicates that there is a short list, the XI2DATANAME data dictionary is used to locate 
the expanded descnption of each of the options on the short list. Thereafter, the short Ts7is displayed 728 
HZ'S^T T£ l ° det6rmine WhSther the US6r WantS the ful ' ,0 "9 list as ind ^ted Si^^nS 
nst^i^eCS E^E^T d6SCribed abOV6 - ' f the " US6r ' S Se ' eC,i0n fr ° m ^ - = 

A check is t hen made at block 734 to determine whether all data is collected. If so. we assemble and emit 
he competed X12 transaction 742 and then exit the routine. With respect to the emitting operation reLrTd 
to ,n conjunct™ w.th 742. the present invention contemplates the capability of maSSte^l^S 

%: itt, r a ; ,in9 the entire trave,iin9 pro9ram - ,f a " data is not c °»- ted tss^xTj^i 

734, then more data items are retrieved and the routine execution is repeated 

Ko„ Jo"' 6 40 T' ateS t0 USe ° f thS trave " ing program in receivi "9 an electronic data interchange transac 

S^TSfS 3 ^T 1 ^ ^ haVe rSCeiVed 3 travelling pro 9™ 9 e "^ted purchae order Sy 

29 In* IS ^ 75 °- Perh3PS by 3 timer -d e,a y ^veiling program, as described with Rgtre 

T Lirl?. Pnf T 6S ° f ,tSe,f 38 inPUt arriV6S - The enCOded EDI is 1 hen P«* '"to program STu«?S? 

Ldit ThT ! ^ T° Ved l ° an arChiVe rep ° Sit0ry to P^^erve t hat which has been received ™ p£2£ 

S X^JJST^S processed ; a a ««PW segment dictionary 756. The segment ^sass'ocTatd 

75B FnrZ^T! T 1 'I may to not havin 9 certain kinds <« data in particular fields 

758^ For each data ,tem, the data dictionary associated with each segment is located 760 For astatZJl 

SoTta^ I"' Wh6re DESC=X12DATA NAME (SEGCODE, DATA ITEM), tS statement^wHI ZuZ a 

2 be rl TV 0 961 3 meanin9fUl deSCripti0n 0f the data item - The re «eved meaningfu | «2S oion 

vter f^t T/J? * VariaWe reSU,tin9 f ° r eXample ' 3 display of tne order in pZ 

^CSilfS are processed by branchin9 back 10 blo< * 762 and a " segments are p ™— d 

^lcn 1 ii^^. a S^' ,M a,l0WS r CeSS 10 3 Digital Notary feci »ty by Providing built-in functions 
Lhth v ♦ ^ 9 u y> ° f "° tary device sucn as described in inventor's U.S. Patent No 5 001 752 

(wh,ch is incorporated herein by reference), or other devices as well 

m-tS'm 'T" 9 !^"? 9 Pr ° 9ram l ° aCCeSS SUCh a faci,it y- the travelli "9 Program is able to move data to a 
nltLZ r r d '? ,ta ' "° tary 03,1 be eaS " y accessed ' then usi "9 the built-in function to do so This allows 
notanzafon for .mportant signatures, timestamps for inbound traffic, or for any other reason See sJcb >2 

Also as described earlier, the facility allows for the coupling to outbound FAX so that electronic form* in 
add,t,on to being converted to EDI, or printed, can also be faxed to the ultima;eTeci P ien. ' 
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Also, as implied, but not explicitly stated, even when a travelling program emits an EDI transaction, it may 
still be activated later. One example would be a travelling program which first serves as an electronic requisition 
then, after sufficient approving signatures, generates a purchase order. It could then send itself to a repository 
5 where it could later be reactivated when the corresponding invoice and bills eventually arrive (electronic or 
otherwise) and can serve as a method for reconciling the order with the shipment received and the billing. It 
can incorporate logic which to keep track of which items have been received, and which are still pending. Be- 
cause of the ability to flexibly direct itself, it can span many different sites. Insofar as handling shipping and 
receiving, it is also possible to couple the travelling program with a bar code reader and validate materials sent 
w and received without human data entry. 

The preferred embodiment envisions that the travelling program could be coupled to a variety of equip- 
ment, including office equipment, and other devices and facilitates. 

Also, any given traversal could also be sent simultaneously to a variety of recipients. 
The following listing reiterates and summarizes many of the above-described functions (and identifies 
is some additional functions) which the preferred embodiment is capable of performing. This list is only illustrative 
and is not intended to be exhaustive of the many other applications to which the present invention may be ad- 
vantageously applied. 

Displaying data to the user using a layout language (similar to, e.g, TxX, or SCRIPT), Soliciting input 
from the user using a layout-type language (similar to, e.g., TeX, or SCRIPT). 
20 Performing digital signatures for data computed under program control. 

Verifying digital signatures based on data computer under program control. 

Handling co-signatures, possibly including routing suggestions derived from the signer's certificates. 

Reading data from user files, 

Creating user files, 
25 Erasing user files 

Writing data into user files 

Renaming user files 

Receiving incoming electronic mail 

Reading the contents of electronic mail 
30 Moving or archiving incoming mail 

Deleting incoming mail 

Generating outbound electronic mail. 

Coupling to and controlling an outbound FAX server 

Coupling to and controlling a printer. 
35 Generating a graphical image. 

Coupling to and controlling a device that can receive and transmit audio signals 

Accessing various types of equipment, including office equipment, computer equipment (tapes, disks, 
etc.) robot devices, manufacturing equipment, etc. 

Splitting an instance of the travelling program into several instances by virtue of multiple traversals. 
40 Being able to re-combine the data contained in the several travelling programs, possibly not even re- 

flecting the same program, into a single form. 

Erasing other instances of travelling programs. 

Invoking external programs. 

Invoking other travelling programs as subroutines. 
45 Activating other travelling programs as independently executing functions. 

Extracting data from a dormant (non-executing) travelling program. 

Determining information about another (non-executing) travelling program without have to execute it- 
- such as name of the program, and other status, etc. 

Extracting information from the certificates associated with digital signatures. This information being 
so used to help direct routing if cosignature requirements are involved. 

Making a copy of a travelling program as a data variable within another program, or ATTACHing a trav- 
elling program as a file to another. 

Using one travelling program (the "carrier") to transport a new version of another to various destina- 
tions, and replacing the program segment of existing instances with another, more up-to-date version of the 
55 program. One way to do this would be for the newer program segment to be added to the end of existing trav- 
elling programs. Enhancements to the existing interpreter/loader would recognize that a program segment fol- 
lowing the closure segment reflected a suggested program revision. After whatever normal transmission was 
performed, it would then validate the digital signatures associated with the proposed revised program, and, 
if they carried the proper authority, would then commence using the new program in place of the program 
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which had arrived as part of the standard traversal 
Attaching user files. 
Exporting attached files into user files. 
Detaching previously attached files. 
Accessing a digital notary device 
Performing a program traversal 



X12 orEDIMCTHL n ™ nC,i0nS ? S """" y »nst, u «ion ,„d re ce,p, of EDI (such as 

the spirit and scope of the appended daims 6qU ' Valent arran 9 ement * hdudad wrthin 



Claims 



7. 



8. 



10. 



I. In a communications system having a plurality of computers (Terminal* A R km „ . ^ 

cuted iLTh? r a / irSt C ° mPUter Wit h 3 SeqU6nCe 0f pr °9 ram instructions (Fig. 2, block 22) which are exe 

SS535S5S5S?—- =» 

forrnedTsatp^t 'a V n a r ' C ° ntent ° f " ^ °" l0giCa ' de ™ and ™<«ons per- 
performing a digital signature (432) on said digital value at at least one destination. 

biSo' :rS"s ;*: r : ln ,hed f t""' ,o s * a si9na »"« -»«■ *- 

any saf of dala ,sad from a user s Ma, data bull, in lo said saquenc. of program IHUta> 
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data entered by the user, data obtained from other signatures, and data obtained from digital certificates 
(514). 

11. A method according to claim 1 further including an indication of the authority which has been vested in 
a user performing a digital signature (432), by including sufficient digital information to allow verification 
that the authority exercised by the signer was properly exercised (434). 

12. A method according to claim 1 further including the step of selecting from a collection of digital certificates 
the certificate to be used in performing a digital signature (434). 

13. In a communications system having a plurality of computers (Terminal a, b, ... , N) coupled to a channel 
(12) over which computers may exchange messages, a method for processing information among said 
computers comprising the steps of: 

providing a first computer with a sequence of instructions (Fig. 2, block 22) which are executed by 
the first computer, including instructions which determine at least one next destination that should receive 
the set of instructions, said set of instructions including instructions for transmitting said instructions to- 
gether with accompanying data to said next destination; 

acquiring data from users of at least one of said computers via execution of said instructions; 
translating said data via the executing of said instructions into a specialized data structure con- 
forming at least in part to a recognized standard whereby said data structure is useful independently of 
said instructions; and 

digitally signing said data structure via the execution of said instructions. 

14. A method according to claim 13, wherein the data is translated under direction of the set of instructions 
into standardized Electronic Data Interchange (EDI) format. 

15. A method according to claim 13, including the step of translating by using an EDI translator. 

16. A method according to claim 15, wherein the EDI translator is an external module which is invoked under 
30 control of said instructions. 

17. A method according to claim 13, wherein at least part of the aggregate of said data structure together 
with the digital signature of said data structure is transmitted as a set of data independently of the set of 
instructions. 

35 

18. A method according to claim 13, wherein at least part of the aggregate of said data structure together 
with the digital signature of said data structure is stored separately from the set of instructions. 

19. A method according to claim 1 3, wherein the result of the digital signature is stored as part of the accom- 
panying data. 

20. A method according to claim 13, wherein the result of the digital signature is verified when the set of in- 
structions is executed at at least one subsequent destination. 

21. In a communications system having a plurality of computers (Terminals A, B N) coupled to a channel 

45 (12) over which computers may exchange messages, a method for processing information among said 

computers comprising the steps of: 

providing a computer with a first travelling program comprising a sequence of instructions which 
determine at least one next destination that should receive the set of instructions, said set of instructions 
including instructions for transmitting said instructions together with accompanying data to said next des- 
50 tination; 

providing at least one of said computers with a second travelling program (Fig. 37:694); 
executing the second travelling program under direction of the first travelling program. 

22. A method according to claim 21 wherein the first and second travelling programs are different instances 
55 of the same set of instructions. 

23. A method according to claim 21 wherein the first and second travelling programs comprise distinct sets 
of instructions. 
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24. A method according to claim 21 wherein the first travelling program presents data to the second travellina 
program which def.nes the operation to be performed by the second (Fig. 37: 694). 9 

25 ' ^^^C 21 Whefein S6COnd traVe " in9 Pr ° 9ram retUfnS data 10 the telling 
26 ' tZ e T d T^? 9 *Z daim 21 Wherei " b0th * rave,,,n 9 pr °9 rams are transmitted in a high-level interpre- 

fypefof^ 

^memoT''" 9 * ^ " ^ "* Pro °™ n tHe SeC °" d *™- ,n 8 P^ram 
A method according to claim 21 wherein the second program instance is preserved after its execution. 
In a communications system having a plurality of computers (Terminal A. B N) coupled to a channel 

TtZZ^^^r** the sei of instructions ' set ° f 

for transmitting said instructions together with accompanying data to said next destination 

providing at least one of said computers with a second travelling program instance (Via 37 694V 
^rocess.ng the second travelling program under direction of insertions in the Hrst SveHing p^ 
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29. 
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31. 



gram instance. 
Cavel^ 

M ' rhT^nH^lr 9 10 C ' aim 30 WhSrein the P r6cessi "9 oP"»«on includes the step of extracting data from 
the second travelling program instance (687, 706). "«"«ing aara irom 

33 ' tT^f aCC °T 9 1 ° C ' aim 30 wherein the processing operation includes the step of altering the proqram 
instructions in the second travelling program instance. 9 pro9ram 

o V fTh 9 «! h0 a d 3 m ° rdi , n9 * Claim 30 Wherei " the P rocess '"9 operation includes the step of altering the value 
of the variables stored in the second travelling program instance. 9 

ir&ISS,^ 30 WhSrein S3id Pr09ram ^ th. same instructions 
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!?£ ^Tr^^'' 0 " 8 SyStem h3Ving 3 P,ura,ity 0f °omputois (Terminals A, B. ... N) coupled to a channel 

^z:^zz s : e 7s T an9e messa9es - a method ,or ~> — a ~ 

providing a first computer with a sequence of instructions (Fig. 2, block 22) which are executed bv 
heS nTT' 6 ?- inC,Udin9 inStrUCti ° nS WhiCh ^^^^^d^S!^^^ 

s ^:^zz°::; sa d H s ? i instructions inc,uding instructi ° ns f0r «« » 

gether with accompanying data to said next destination; and 

selecting a file in response to execution of said sequence of instructions- 
t« ' ransm ' tt,n9 ^: atleastpart of the content of said selected data file to said next destination in response 
to execution of said sequence of instructions; (Fig. 35. 36, 37, 640-642. 680-708. 710-732) 

37. A method according to claim 36, including the step of digitally signing at least part of the data of said file. 
38 ' ofTa'wf ife 30 ' 0 ^ 1 " 9 10 C ' aim 36 ' indUdin9 tHe S,eP ° f COmputin 9 a hash va,ue <* at least part of the data 
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39. In a communications system having a plurality of computers (Terminals A, B, ...N) coupled to a channel 
(12) over which computers may exchange messages, a method for forwarding information in said com- 
munications system comprising the steps of: 

5 providing a first computer with a set of instructions (Fig. 2, block 22) which are executed by the 

first computer including instructions which generate a plurality of instances of said set of instructions and 
which initiate transmission to at least a first and a second destination which respectively receive one of 
said instances together with accompanying data; and 

including within said instances transmitted to said first and second destinations the capability of 

w subsequently merging data that has been accumulated during their distinct transmission paths (Fig. 37). 

40. A method according to claim 39, further including the steps of: 

establishing one instance as the master instance (682); and controlling, the master to extract data 
from other instances as they arrive at the merging destination. 

15 

41. In a communications system having a plurality of computers (Terminals A, B, ... N) coupled to a channel 
(12) over which computers may exchange messages, a method for processing information among said 
computers comprising the steps of: 

providing a first computer with a sequence of program instructions (Fig. 2, block 22) which are exe- 
cuted by the first computer, including instructions which determine at least one next destination that 
should receive the set of instructions, said set of instructions including instructions for transmitting said 
instructions together with accompanying data to said next destination; and 

qualifying the set of operations which said sequence of instructions is allowed to perform. 

25 42. A method according to claim 41, wherein said qualifying means are specified by a party using said pro- 
gram. 

43. A method according to claim 41 , wherein said qualifying means are digitally signed by a party trusted by 
the parties using said travelling program. 

30 44. In a communications system having a plurality of computers (Terminals A, B, ... N) coupled to a channel 
(12) over which computers may exchange messages, a method for processing information among said 
computers comprising the steps of: 

providing a first computer with a sequence of program instructions (fig. 2, block 22) which are exe- 
cuted by the first computer, including instructions which determine at least one next destination that 
35 should receive the set of instructions, said set of instructions including instructions for transmitting said 

instructions together with accompanying data to said next destination; and 

performing a digital signature by using a private key stored in a user token device. 

45. A method according to claim 44 including the step of determining whether the user's private key is stored 
40 in a token device or in computer memory, and the step of processing the signature with the said token 

device or in the user's computer, respectively. 

46. In a communications system having a plurality of computers (Terminals A, B, ... N) coupled to a channel 
(12) over which computers may exchange messages, a method for processing information among said 

45 computers comprising the steps of: 

providing a first computer with a sequence of program instructions (Fig. 2, block 22) which are exe- 
cuted by the first computer, including instructions which determine at least one next destination that 
should receive the set of instructions, said set of instructions including instructions for transmitting said 
instructions together with accompanying data to said next destination; and 

so performing a date/time notarization. 

47. In a communications system having a plurality of computers (Terminal a, b, ... N) coupled to a channel 
(12) over which computers may exchange messages, a method for processing information among said 
computers comprising the steps of: 

55 providing a first computer with a sequence of program instructions (Fig. 1 , 22) which are executed 

by the first computer, including instructions which determine at least one next destination that should re- 
ceive the set of instructions, said set of instructions including instructions for transmitting said instructions 
together with accompanying data to said next destination; and 
performing a time delay function (Fig. 9: 570). 
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